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(54) Abstract Title: Race betting system 

(57) In order to allow a person remote from a race, such 
as a horse race, to bet on and view the race, there is 
disclosed an interactive race betting system 
comprising race data input means (including 
totalisator 112 and race course data centre 113) for 
providing data including an identification of at least 
one race and race data relating to runners in the race. 
The race data is stored in a race database 106. A 
processor 103 is provided for transmitting race data 
to a betting terminal in the form of PC 101 or 
telephone with screen 117. The PC 101 or telephone 
117 can be used to input bet data including a 
selection of at least one race, a selection of at least 
one runner and an identification of the betting 
terminal. This bet data is stored in a bet data store 
105. The betting terminal 101 or 117 may also be 
used to deliver a request for video. The processor is 
configured to only allow video to be transmitted to 
the terminal if the user of the terminal has bet on the 
race for which a video has been requested. Video can 
then be transmitted to the betting terminal from the 
video supplier 120 at the time that the race is run. 
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R ACF RFTTNG SYSTF.M AND PROCESS 

The present invention relates to a race betting system and a race betting process. 
Betting on races, for example horse races, bicycle races, greyhound races and other 
types of race, has long been extremely popular. However, it has only been possible in 
the past to bet on such races by attending a racetrack in person. Off-track betting 
establishments have been established for a long time allowing users to place bets on 
races whilst not attending the racetrack, but it is still necessary to travel to the off-track 
betting establishment. Great interest has been shown in interactive wagering systems 
and processes which can be carried out anywhere by placing a user in communication 
with an interactive wagering system via communication systems. 

For example. WO97/09699 discloses an interactive wagering system and 
process in which a data facility is provided which receives wager data and provides 
racing data combined with video signals. The user is provided with a user terminaJ for 
receiving video signals and racing data and for displaying the video signals and racing 
data on a monitor. The user is provided with input means for inputting wager data 
which is relayed to the data facility via transaction data communication circuitry. In 
this way, a user is enabled to place wagers interactively on forth coming races and view 
the races via the monitor. The data facility further comprises wagering accounts and 
means for crediting or debiting the wagering account of a user to reflect the wagering 
activity of the user. 

This system is particularly suitable for use with a totalisator. A totalisator is a 
piece of equipment which allows a large number of individual users to engage in what is 
known as Pari Mutuel betting. In this system, users place bets upon a number of 
possible outcomes. For example, in a horse race, a user may place a bet on a particular 
horse winning a particular race. The total stakes placed by all users are collected and a 
certain fee is deducted for administration. The remaining sum is divided among users 
who selected the correct winning horse. A winning user's proportion of the total money 
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is equal to the proportion represented by that user's stake of all the stakes placed upon 
the winning horse. 

Similar systems are disclosed in WOOI/03088 and WO01/03089. In WO01/03088. 
users are enabled to record races for subsequent viewing. A general archive is provided 
which may be searched by users to view previous races. 

In WO01/03089. a television channel may be provided which is dedicated to racing 
activities. Notices may be displayed on the screen whilst programmes about racing are 
playing notifying a viewer of an opportunity to commence interactive wagering on races 
or runners which are being featured in television programmes. 

There is great demand on the part of users to view races either as they occur or 
afterwards. Typically, however, video data which has to be sent to a user to allow the 
user to view the video can only be transmitted via a carrier with a high data capacity, in 
view of the large amount of data required to display the images. 

A method disclosed in for example WO97/09699 is to provide video data on a 
television channel such as cable, satellite or terrestrial television. Such channels are 
well designed to handle video data which can consequently be streamed continuously. 

Howeven such a system requires a specialised receiving apparatus for receiving 
television programmes. Where a user is receiving and video data via a communication 
link such as a modem or telephone line, it is impractical to continuously stream the race 
data and video data to the user, because the user may wish to use their communication 
link for other purposes. 

In ,WO01/03088, races can be recorded either centrally at the race data management 
facility or on the user's video cassette recorder. However, the races can only then be 
viewed by replaying the recording after the race is finished. 

In order to record the race on the user's video cassette recorder, the system 
automatically tunes the recorder to receive the video signals when the video signals are 



sent. However, this is not practical when another application is used, such as a personal 
computer, as the user may wish to use it for another purpose. 

In WOO 1 /03088, video signals are transmitted on the basis of a pre-arranged race 
schedule. However, there can be problems if the races do not occur according to the 
time schedule. 

It is an object of the present invention to allow users to view races on which they have 
bet at substantially the same time as the race is occurring. It is an object of the 
invention to allow the user to only receive such video signals if they want and when 
they want without being obliged to dedicate their communication apparatus to the 
source of video signals except for the brief period of time during which the video 
signals are being transmitted. The present inventors have realised that a race betting 
system can be configured to monitor the status of a race on which users have bet and to 
give users notice of when the race is about to begin, so that users can select whether to 
view video of the race or not. 

By monitoring the race condition rather than referring to a race schedule, problems of 
late race starts can be avoided. 

By providing theusers with an opportunity to select whether to view the race or not, 
there is no need for the user's communication facility to be permanently tuned to the 
source of video signals for longer than the duration of the transmission. 

Accordingly, the present invention provides an interactive race betting system 
comprising means for transmitting race data to a remote betting terminal, bet input 
means for receiving bet data from a betting terminal, the bet data including a selection 
of at least one race and at least one runner in the race and an identification of the betting 
terminal, bet data storage means for storing the input bet data as a data entry, race data 
input means for receiving race data, the race data including an identification of at least 
one race and data relating to runners in the race, 

means for receiving from a requesting betting terminal a request for video of at 
least one race. 
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a processor configured to inspect the bet data in the respective storage means 
when a request for video is received, and to give a signal if the at least one race is 
identified by at least one data entry in the bet data storage means which also identifies 
the requesting betting terminal and 

means for allowing in response to the signal the requesting betting terminal to 
display video of the at least one race. 

The present invention further provides, a method of interactive race betting, 
comprising receiving race data, the race data including an identification of at least one 
race, the status of the race and data relating to runners in the race. 

transmitting race data to a remote betting terminal, receiving betting data from a 
betting terminal, the bet data including a selection of at least one race and at least one 
runner in the race and an identification of the betting terminal, storing the bet data in a 
bet data store as a data entry, receiving a request for video from a requesting betting 
terminal, inspecting the bet data store when a request is received, giving a signal if the 
at least one race is identified by at least one data entry in the bet data store means, 
which also identifies the requesting betting terminal and allowing in response to the 
signal the requesting betting terminal to display a video of the at least one race. 

The present invention also provides programme code for controlling one or more 
processors to implement the method. The betting method of the present invention is 
carried out electronically. The betting system suitably comprises electronic data 
handling means, for example at least one computer, for example a personal computer. 
The data handling means is preferably connected by transmitting means such as a 
modem to a communication network, for example the Internet, an Intranet or a 
dedicated communications system. 

In a further aspect, the present inventions provide a carrier medium carrying the 
computer programme code according to the invention. 

The computer may communicate with the user by any convenient communication 
means, but the system is particularly suited to implementation over an electronic 
communications network employing an Internet protocol, such as an Intranet or extranet 
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communication network or the Internet or World Wide Web. In this case, the software 
applications may comprise or consist of instruction codes, for example for web data 
pages, such as HTML (Hypertext Markup Language) code, XML (Extensible Mark-up 
Language) code, and/or Java. ActiveX trade mark) or Perl code or scripts in other 
programming languages. 

The means referred to may all be software such as program code and / or instruction 
code for internet/web data pages in HTML. XML, Java or similar. Generally speaking 
they will each comprise coded instructions for a computer and may be separate 
applications or parts of a single program. 

The present invention can be embodied in computer program code, and as is well 
known to those skilled in the art. the program may be implemented at a client computer 
or a server computer as desired. Computer programmes may be provided to the 
computers by any conventional carrier medium such as tape. disc, program memory or ' 
other storage media or. alternatively, a program may be provided via a communication 
network such as an electrical signal. 

The processor for implementable instructions of one or both of the systems may be 
provided on a data carrier or storage medium such as a hard or floppy disc, ROM or 
CD-ROM or an optical or electrical signal carrier. The processor implementable 
instructions of the betting terminal may be stored in the data store of network server 
such as a web server for example as part of a page of Internet data such as a web page. , 
In another aspect, the invention provides a data carrier carrying a processsor 
implementable instructions for the betting system. 

The present invention will be hereinafter described with reference to horse racing, but it 
will be understood that this is an embodiment only and the system may be equally 
applied to any other form of racing. 

The race data may be input to the system by any suitable means. For example, race data 
may be typed in using a keyboard. Alternatively, the race data may be received in the 
form of a signal from a race data supply terminal. For example, such a signal may be 
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received via a communications network or via dedicated communication lines such as 
telephone lines. Race data may be input also by other means, such as scanners, or by 
the use of data carriers such as discs, programmed with race data. The race data will 
include at least an identification of at least one race and data relating to runners in the 
race. 

The race may be identified by specifying at least one racecourse, being a geographical 
location of the race and an identification of the race, for example by race time or name. 
Suitably, all of this information is provided. 

The race data may further include information such as the type of class or race (for 
example, in horseracing. whether it is a fiat race or steeplechase), the distance over 
which the race is run. and prizes awarded to winners in the race. 

The race data relating to horses running in the race suitably includes an identification of 
each horse, for example the name of the horse and the means of identifying the horse, 
for example the saddle cloth number and/or racing colours. 

Suitably, further horse data is selected from any or all of: 
the name of the jockey 
the name of the trainer 
the rating of the horse 
previous form for the horse 
comments on the horse from experts 

status of the horse (whether still running or scratched from the race, i.e. 
removed and not running for various reasons) 
the age of the horse 
the weight carried 

These data may be provided by race courses or by established race data agencies, such 
as Tattershall's or Weatherby's. 

Further race information may be selected from: 



weather at the race course 

condition of the course at the race course 

pictures of the race course 

pictures of the horses and/or jockeys 

diary information, setting out the date and location of f6rth coming races 
whether or not bets may be made on forth coming races. 

Different items of racing data may be input by different sources. For example, data 
relating to horses running may be obtained from the racecourse itself. However, 
comments on the horses running may be obtained from independent experts using 
different input means. 

The race data will further include the status of the race. The status data may be selected 
from: 

Jockey close - indicating that betting is not yet open 

Going down - horses proceeding from the parade enclosure to the starting gates, 
betting permitted. 

At the post. Horses have reached the starting point for the race, betting is still 
permitted. 

( Going behind. Horses entered into the starting gates; betting still permitted. 

Betting no longer permitted. 

Specification of expected time before the race commences. 

Race status data may be input by any suitable means. Preferably, the system is 
configured to receive race status data from a racecourse itself. This data may be 
received directly from the racecourse or indirectly. For example, this data may be 
received from a totalisator. as explained further below. It is preferred that the race 
status data is received substantially in real time. That is, it is preferred that it is not 
deduced from a pre-determined schedule. In this way. alterations due to delay in the 
racing schedule can be allowed for. 



Race data may be sent to a betting terminal by any suitable means. The race data sent 
the betting terminal may be selected from the race data received by the system. The 



race data may be sent at regular intervals to the betting terminals. However, it is 
preferred that race data be sent to the betting terminal upon request from the betting 
terminal. For example, it is preferred that the betting terminal and system be in a client- 
server relationship. 

It is particularly referred that the race data is held at an information site on the system, 
the information site being accessible by accessing means of the betting terminal 
whereby the betting terminal may act as a user interface means. Il is particularly 
preferred that the information site comprises a web page. Suitably, the. access means 
comprises processing apparatus operating a web browser application. 

Suitably, the race data is provided to the betting terminal in a plurality of steps 
responsive to requests from the betting terminal. 

For example, in a first step, a request may be received from the betting terminal for data 
relating to races occurring on a selected day. In response, data relating 10 races for the 
selected day may be sent to the betting terminal so that the user may use the betting 
terminal to select a particular race. In response to this selection, the system may send to 
the betting terminal a list of allowable bet types. These may include any bet types 
which are known in the art, being suitably selected from: 

Win - the selection of a horse to finish to first place in a selected race 
-Place - the selection of a horse finished first or second in a selected race 
Exacta - the selection of the first two horses finishing, in the exact order, for a 
selected race. 

Trifecta-the selection of a horse to finish first, second or third in a selected 
race. 

Jackpot - the selection of a single horse to finish first place in a single race. 
Placepot - the selection of a horse to finish first or second in a selected race. 

The system may be configured to send, in response to the selection, data relating to the 
horses running in the selected race. 
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The data may be sent to the betting terminal to configure the betting terminal in the 
form of a user interface. The configuration data sent to the betting terminal suitably 
depends upon the type of bets selected. For example, where a win bet is selected, the 
user interest will comprise a single field for completion by the user with the name of a 
single horse. 

Finally, the system may be configured to receive from the betting terminal an indication 
of the stake to be placed by the letter for the bet. 

This series of steps may be operated in a different order. For example, the system may 
receive from a betting terminal a request for a list of races in which a given horse is 
running. The system may be configured to respond to such a request by sending a list 
of races in which the horse is running to allow the user to select a given race, followed 
by a particular type of bet. 

In a preferred embodiment, the bet data is sent to the betting terminal in the form of a 
web page. The web page may be configured to resemble a conventional race card of the 
type typically issued to betters attending a racetrack. 

Other data may be sent by the system to a betting terminal. For example, data may be 
sent to configure the betting terminal to provide the user with the option of withdrawing 
from a bet or correcting a bet. 

The system may be configured to transmit the submitted bet data to the betting terminal 
for confirmation. The system may be configured to receive a confirmation signal from 
the betting terminal whereupon the bet is recorded in the bet data store and is deemed to 
be placed. 

The bet data included in the bet data store must include an identification of the betting 
terminal. This identification may comprise a name, code number, code word, password 
or the like. It may suitably include an e-mail address whereby an e-mail message may 
be sent to the betting terminal. 
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The bet data included in the bet data store may include an identification of the user. 
Normally, users will access the system of the present invention from the same betting 
terminal each time so that in many cases a request from a given betting terminal will 
imply request from a given user. However, this is not necessarily the case, and the 
system may be configured to send a request for an identification of the user to the 
betting terminal. This user identification may include the name and a password of the 
user. 

In a preferred embodiment, the system will, in response to a request from a betting 
terminal, sent to that betting terminal a copy of all data in the bet data storage which 
includes the identification of the respective betting terminal. 

The system is suitably configured to process bet data input to allow potential winnings 
to be calculated in a conventional manner. The system may be used for fixed odds 
betting but it is preferred to configure the system for totalisator betting- 

Accordingly, the system is suitably configured to transmit the bet data to a totalisator. 
Such bet data should include a reference identification. For reasons of confidentiality, 
the name, e-mail address or other recognisable identification of the betting terminal is 
suitably not used. Suitably, the system is configured to attach to each betting data entry 
a unique reference identification. 

Suitably, the betting system comprises an account management means, comprising 
account data store means storing account data comprising, for each betting terminal, at 
least an account bajance. The account management means may be configured to set a 
limit on the amount of credit which may be entered against a given betting terminal. In 
this way, when betting data is received from a betting terminal, the account 
management means may be configured to inspect the account data store and the amount 
of the stake in the betting data and the credit limit of the user to see if the credit limit 
will be exceeded. If the credit limit will be exceeded, the processor may be configured 
to send a message to the betting terminal refusing to accept the bet. 
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Suitably, the system is configured to receive from race result data, preferably from a 
totalisator. Such result data suitably includes an identification of a particular race, an 
identification of the order in which horses crossed the finishing line, an identification of 
sums won. accompanied by reference identifications to identify which betting entries 
, won which sum. The system is preferably configured to search the bet data store to 
locate the bet data entry to which the reference identification corresponds and to credit 
the account of the betting terminal by the user identified by the bet data entry with a 
sum corresponding to the sum won. 

Win data may be transmitted to the betting terminal to notify the user that they have 
won a given sum of money. 

The system may be configured not to make race data available to a betting terminal 
unless the user of the betting terminal is a subscriber to the system 

The betting system may be configured to receive a request from a betting terminal to 
subscribe to the betting system. In response to such a request, a request for information 
may be sent to the betting terminal. The information requested may be selected from: 

- betting terminal data, selected from: specification of the betting terminal, type 
of betting terminal (PC or MAC), available memory space, available software. 
If suitable software is not available, the belting system may be configured to 
identify to the betting terminal a site from which software can be downloaded. 

- name 

selected password (this may be selected by the user of the betting 
terminal or allocated automatically by the betting system) 

- y other identification data (for example, date of birth, address etc) 

contact details (e-mail address, telephone number, fax number etc - 
financial data, including name of users financial institution, account 
number, type of account, sorting code etc. 

Suitably, the system is configured to request the user to insert a password. The system 
may then be configured to transmit a request to the betting terminal for the user to 
confirm their password. 
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It may also be necessary to check the age of the user and the user's location. In some 
parts of the world betting is only permitted in certain states. 

As part of the subscription procedure described above, the system may be configured to 
transmit a payment request to the betting terminal, to request the user to put the account 
of the respective user in credit or so that a part or all of outstanding debits may be paid 
off. The payment may be made by any suitable means, for example manually by 
despatch of a cheque or payment order. Alternatively, it may be made electronically by 
bank transferor it may be paid from the user's debit card or credit card. 

The system may be configured so that, when it receives a request from a user to 
commence betting, the system transmits to the betting terminal a request for log-on 
information. The log-on information may include the name of the user of the betting 
terminal and their password. Other information may be requested. The system may 
then be configured to receive the completed log on information from the betting 
terminal and to compare the completed log in information with records of user names 
and password. If the entered user name and password matches data in the user name 
record, the system is configured to accept further requests from the betting terminal. 

In the normal way. the user may be allowed a specific number of attempts to enter the 
correct password. If the password is not entered correctly in the specified number of 
attempts, logon may be denied or. alternatively, the processor may be configured to 
transmit to the betting terminal a second request in which other data specific to the user 
is requested, for example date of birth, key facts or bank account details. 

The system may be configured to provide to a betting terminal racing related 
information upon request. For example the racing related information may be selected 
from the following: 

Weather forecast for general area or for a specific racecourse 

General news related to racing or racecourses 

Features and articles 

Expert assessment of horses (including tips, speed ratings, etc.) 
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In order to provide such details, the system is suitably configured to receive general 
data. General data may be input by any suitable means for example by keyboard, by a 
communication network such as the Internet, and Intranet or other network, by 
dedicated telephone lines from suitable sources or in the form of pre-recorded material 
on data carriers. 

The system may be also configured to provide estimates of the winning payout if a bet 
is placed upon a given horse. This data may be obtained from general sources in 
manner described above. However, this information is generally provided by totalisator 
systems and the processor may be configured to receive the information directly from 
the totalisator system. 

The system is configured to inspect the bet data store when at least one race reaches a 
defined status. This define status may be "betting closed" or "going down" or "n 
minutes to start" wherein n is a defined amount. However, in a preferred embodiment, 
the defined status is that the video signals are available of the race or preparations for 
the race The monitoring means may be configured to monitor incoming race data. The 
monitoring means may comprise means for receiving a signal that video signals are 
available. The process or may be provided with signal input means for receiving the 
signal. The signal may be input by a suitable means, for example via communications 
network, via dedicated telephone lines or by a manual input from an operator at the race 
track or by an operator of the sy stem. For example, the operator of the system may 
monitor general incoming video signals and, at a point to be determined by the operator, 
decide that commencement of the video supply may begin. 

The processor is suitably configured to receive a signal which indicates that video is 
now available, the signal also identifying the race for which video is available. The 
processor is preferably configured to search the bet data store or race data store for a 
race corresponding to the race identified by the signal, and to enter in the bet data store 
or race data store on a note that the video is available for the race. 
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The processor may be configured to give a signal if the at least one race for which video 
is available is identified by at least one data entry in the bet data storage means. Where 
the at least one race is identified in a plurality of data entries, a signal is preferably 
given for each data entry. 

In order to allow a terminal to receive video, code may be transmitted to the betting 
terminal. 

The code transmitted to the betting terminal may be any suitable code. It may be 
configured to allow the betting terminal to access video data. The system may be 
provided with means for transmitting video signals of the at least one race, the code 
transmitted to the betting terminal being configured to allow the betting terminal to 
access the means for transmitting video signals. For example it may include a 
password.or other enabling software. In the alternative, the source of video data may be 
located separately from the betting system. In this case, the code transmitted to the 
betting terminal may be sufficient to identify to the betting terminal the source of video 
data. For example, the code may comprise a communication system address, such as an 
e-mail address, telephone number, channel number or the like. 

The system may be configured to receive communication system addresses for each 
video of each race. The system may be configured to store each address of each video. 
Preferably, the communication system address changes from race to race, so that the 
user can only view the race which is being transmitted from the given communication 
system address and no subsequent or simultaneous video. 

This system is considered to be inventive in its own right. Accordingly, in a further 
aspect, the present invention provides an interactive race betting system comprising: 

race data input means for receiving race data, the race data including an 
identification of at least one race and data relating to runners in the at least one race, 

race data storage means, 

means for transmitting race data to a betting terminal, 
bet input means for receiving bet data from a betting terminal, the bet data 
including a selection of at least one race and a selection of at least one runner 
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bet data store means for storing the input bet data as a data entry, 

means for transmitting a request for race video location data to a video data 

source, means for receiving from the video data source the race video location data and 

a video location data store for storing the race video location data 

means for receiving a request for video of at least one race from a requesting 

betting terminal, 

a processor configured to search in the race video location data store for video 
location data relating to the selected race and. in order to allow the betting terminal to 
display video of the selected race, to transmit to the betting terminal the video location 

Preferred features of this aspect of the invention are as for the other aspects of the 
invention. 

The code permits the betting terminal to receive substantially live and real-time video of 
the race. In this context, "substantially real-time" means that a time period of no more 
than a few minutes, preferably no more than ten minutes and more preferably no more 
than two minutes elapses between the generation of video signals at the race and the 
receipt of the video signals by the betting terminal. 

In a totalisator system, betting terminates before the beginning of the race, so slight 
delays in transmission of video signals are acceptable because they will not compromise 
the security of the betting. 

Preferably, the code transmitted allows the betting terminal to receive streamed video 
signals. In this way. the user does not have to wait for the entire transmission to be 
downloaded before it can be viewed. 

A suitable system for viewing video on the betting terminal comprises Realplayer 
software (trade mark) or Mediaplayer (trade mark) 
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The code transmitted to the betting terminal may be configured to allow the betting 
terminal to receive audio signals relating to the race in an addition to the video signals. 
For example, audio signals may be transmitted on a side band of the video signals. 

Because the video is typically copyright material, it is preferred that steps are taken to 
prevent unauthorised copying of the material. 

A user may be permitted to download a video of a race which has finished. The system 
may be configured to send a request to the betting terminal for payment of a licence fee 
todownload the video. 

A licence fee may be requested per video downloaded. In.the alternative, the licence 
fee may be a blanket licence fee of a defined term, for example of the term of a month, 
two months or a year, as appropriate. The blanket licence fee may permit the user to 
download any videos within the term of the licence. 

The processor may be configured to receive from the betting terminal a request for an 
archived video to be downloaded. The processor may be configured to inspect the 
betting terminal licence storage means to see if the betting terminal is associated with a 
suitable licence. The systems may be configured to send a signal indicating that the 
request is refused, if the user has no licence. 

In the alternative, the system may be configured to transmit to the betting terminal data 
representing the archived video accompanied by key means, the key means comprising 
code which will allow the video to be viewed only within a specific time period 
representing the licence term of the licence purchased by the user. 

Preferably, the processor is configured to record in a data store whether or not a key 
means has been transmitted to a given a betting terminal or user and to identify the term 
associated with the key means. If a request is subsequently received from a betting 
terminal to view archive video, the processor is suitably configured to inspect the data 
store to see if the user has paid a licence fee and to see if the user has already received 
key means. If the user has already received a key means and the term of key means has 
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not yet expired, the processor is suitably configured to send archive video to the user 
without attaching a key means. This is particularly appropriate where the key means 
represent a blanket licence which allows the user to watch any number of videos within 
a specified time period. Each time period is represented by single key means. 

Suitable software for transmitting key means is available under the name BRM (trade 
mark) 

The betting system may be configured to receive race results. The race results may be 
input by any suitable means. They may be input by keyboard. Alternatively, they may 
be received via a communication network or via dedicated communication links. They 
may be obtained from a totalisator. from a source of information, such as Tattershalls or 
Weatherby s or from a racecourse. 

The race results may be "unofficial" results obtained by a viewer of the race assessing 
the order in which the horses completed the race. However, it is not uncommon for the 
results of races to be unclear, if at least two horses pass the finishing line very close 
together. In such cases, the race track normally commissions an enquiry to determine 
which horse finished first. This may take some time so that official results may only be 
available after a period of may be one day. 

The processor may be further configured to send to the belting terminal odds 
information, allowing the user to see what odds are being laid against a particular horse 
winning a race. 

. The system may further include a research database. The research database may be 
configured for storing information relating to any of the following: 
Horses 
Trainers 
Jockeys 
Racecourses 

Races 1 
Results 
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The processor may be configured to receive a request for a search from a betting 
terminal. The search may comprise a name, or a string of letters which form a part of a 
name or other information which the user operating the betting terminal wishes to 
search. For example, if the user wishes to look for information about a horse called 
lucky lad. the user may enter the letters LUC at a betting terminal and transmit a request 
for a search on horses with this name. 

The processor is then configured to search for all entries relating to horses which match 
the search parameters. The processor is also configured to send a list of data entries 
which match the search parameters. The user may then send request for further 
information via the betting terminal, for example seeking the horse's history, parentage, 
results in previous races, weight, age etc. In this way, a user can very rapidly obtain 
information which will allow the user to make suitable betting decisions. 

The search may be launched from an information site being contacted by user interface 
means. For example, the information site may comprise a web page and the user 
interface means comprises a web browser on the betting terminal. 

Many users are interested in following the fortunes of a particular horse, which they 
believe has potential to win many races. Accordingly, the present invention preferably 
provides user preference store. The system is suitably configured to receive from a 
betting terminal an identification of at least one horse which is of general interest to the 
user. The system is then configured to enter the name of this horse in a user preference 
store database together with an identification of a betting terminal of the user who has 
selected the horse. 

The system may then be configured to inspect the race database at regular intervals to 
find if a horse which is entered in the user preference store also appears against any 
races in the race database. If a match is found, the processor is configured to send a 
message to the betting terminal identified with the horse in the user preference store 
offering the user an opportunity to bet on the horse. , 
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This facility is considered to be inventive in its own right. 

Accordingly, in a further aspect, the present invention provides an interactive race 
betting system comprising: 

race data input means for receiving race data, the race data including an 
identification of at least one race and data relating to runners in the at least one race, the 
racecourse, trainer or rider, 
race data storage means, 

means for receiving from a betting terminal option data relating to at least one of a 
runner, race, racecourse, trainer or rider. 

an option data store for storing the option data received as a data entry, 
a processor configured to inspect the race data store at regular intervals and the option 
data store and. if data in the race data store matches data in an entry in the option data 
store, to transmit to the betting terminal identified by the option data entry, the race 
data of the data entry, and 

bet input means for receiving bet data from the betting terminal. 

Preferred features of this aspect are as for the other aspects of the invention. 

The user database may permit the user to select upto any given number of horses, for 
example upto ten horses. 

It may happen that after a successful season, an account against a given betting terminal 
is substantially in credit. The user may wish to withdraw funds from the account in 
order to recoup their winnings. Accordingly, the account management means is 
suitably configured to receive an instruction from a betting terminal to pay out money 
from the user account. The account management means is suitably configured to 
compare the request for withdrawal of funds against the funds listed in the account to 
confirm that there is sufficient money to meet the request. If sufficient money is 
present, the account management means may send a request to the user to identify 
which form of payment is preferred. For example, the payment form be selacted from: 
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Despatch of a cheque to the user 
Payment to the user's bank account 
Payment to the user's debit card 

In order to allow a user to operate the account management means, the account 
management means may be configured to send to the betting terminal an identification 
request, requiring at least one form of identification, for example, a password, from the 
user. The account management means is preferably configured to request at least two 
forms of identification and may be more. For example, the account management means 
may request bank account data, bank account sort code, debit card number, debit card 
sort code and debit card expiry date. 

Once the account management means has received this information, it may be 
configured to send back a checklist of the information to the betting terminal for the 
user to confirm. 

The account management means may be configured, to send account details lo a betting 
terminal upon request by a duly identified user. 

The system of the present invention may provide other services to users. These services 
may be selected from: 

To allow the user to play a game, for example a computer generated horse- 
racing game. 

To allow users to enter a quiz 

To provide a message transmission means, for example an e-mail facility or 
bulletin board 

To provide help for users 
To provide tips on races 

To provide an opportunity to make purchases of racing related goods or other 
promotional material. 
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These services may be made generally available to users or they may require the user to 
make payment of a fee. The account management means may be configured suitably to 
process the payment of a fee for the subsidiary services. 

The present invention will further be described by way of example only with reference 
to the accompanying drawings, in which: 

Figure 1 is a schematic illustration of a race betting apparatus according to the 
present invention. 

Figure 2 is a schematic illustration of the totalisator system for use in figure 1 . 
Figure 3 is a schematic illustration of an arrangement which may be used in 
figure 1 for providing video of races. 

Figure 4 is a schematic illustration of the race database of figure I . 
Figure 5 is a schematic illustration of the user database of figure 1 
Figure 6 is a schematic illustration of the account database of figure 1 
Figure 7 is a schematic illustration of the archive database of figure 1 
Figure 8 is a schematic illustration of the research database of figure 1 . 
Figure 9 is a schematic illustration of the steps involved in registration a new 

user. 

Figure 10 is a schematic illustration of the steps involved when a user logs onto 
the system. 

Figure 1 1 is a schematic illustration of the steps involved in entering horses' 
names in the user database. 

Figure 1 2 is a schematic illustration of the steps involved in placing a bet by 
selecting a horse 

Figure 13 is a schematic illustration of the steps involved in placing a bet by 
selecting a race. 

Figure 14 is a schematic illustration of the steps involved in entering bet data. 
Figure 15 is a schematic illustration of the steps involved processing bets placed 
on the system. 

Figure 16 is a schematic illustration of the steps involved in providing video of a 

race. 



22 



DETAILED DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic illustration of an apparatus for interactive betting according to 
the present invention. 

At the heart of the apparatus I is the system 102 according to the invention. The system 
102 comprises a processor 103. The processor 103 is configured to receive data inputs 
from a wide range of sources. Suitably, the processor is configured using Broadvision 
(Trade Mark) software which allows it to manage a plurality of inputs and outputs. 

The processor 1 03 is connected to at least two communications networks. It is 
connected to the internet 1 00 and also to the public switch telephone network (PSTN) 
118. It may also be connected to other communications networks, for example a 
television signal distribution network (not shown). 

Also connected to the internet 100 and the public switch telephone network 1 1 8 is a 
user's financial institution 1 1 5, for example a bank. 

Also connected to the internet is a betting terminal 101 in the form of a user's PC. Also 
connected to the public switching telephone network is a user's telephone 1 17 which 
incorporates a video screen 122. 

The processor is configured to receive data inputs from a racecourse 1 09. The 
racecourse 109 is provided with a racecourse data centre 1 13 at which various types of 
data may be input, for example relating to the weather at the racecourse, the going of the 
ground, the number of runners, the status of the race, late removals from the race 
("scratches") or other suitable information. The processor may receive data directly 
from the racecourse data centre 1 13 or it may receive it by the intermediary of a general 
data centre 110. 
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The general data centre 1 1 0 may also provide further data to the processor, for example 
race listings in advance, race timetables, archive data about runners and riders, etc. An 
example of a general data centre in the United Kingdom is the Wetherby's race 
information service or Tattershalls. 

The processor 103 is further connected to a totalisator system 1 12. The totalisator 
system 1 12 is further described with reference to Figure 2 below. The totalisator system 
1 12 is configured'to receive betting data from the processor 103 and to transmit 
confirmations of betting data, odds data, running data, race status data and results data 
to the processor. 

Processor 103 is connected to a video supplier 120. The video supplier 120 receives 
video signals recorded live at the racecourse via camera 111. The video supplier 120 is 
further connected to the internet 100 as shown. It may also be connected to the PSTN 
1 1 8 or other communications network in the manner which is not shown in Figure 1 . 
The video supplier 120 further comprises a video storage unit 121 for archived video 
which will be explained further below. 

The processor 103 may also receive manual inputs from a keyboard 123 or a data 
reading device 124 for reading data entered on a carrier medium. The processor 103 is 
further connected to an account database 104. The account database is configured to 
contain information about user accounts. The processor 103 may enter data into the 
account database 104 or read data from it. The processor 103 is further connected to a 
bet database 105. The bet database 105 is configured to hold bets. It is also configured 
to hold information concerning users, including the user's account number, user's list 
of preferred horses, bets placed by the user and the like. The processor may enter data 
into the user database or read data from it. 

The processor 1 03 is also connected to a race database 1 06 in which race data is entered 
and from which race data may be read. The processor 103 is further connected to an 
archive database 1 07 in which information relating to races which have been completed 
may be entered or read. ' 
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The processor 103 is further connected to a research database 108 containing 
information about matters such as jockeys, trainers, horses, race tracks or results from 
the past. The processor may enter data into the research database 108 or read from it. 

The processeor 103 is further connected to a video database 125 containing information 
about live and archived videos of races. The processor may enter data into the video 
database 1 25 or read data from it. 

Figure 2 is a schematic illustration of a totalisator system 112. The processor 201 of a 
system according to the invention is shown at the top of the diagram. It is connected to 
a first totalisator. totalisator I . Totalisator 1 may also be connected to second and third 
totalisators 204 and 21 1 . 

Totalisators are well known in the art and are available for example from Amtote 
International or Autotote Inc. of the United States. A well known protocol for passing 
betting information between totalisators is established, referred to as ITSP (lntertote 
Tracking Service Protocol). It will not be described further here. Totalisators 204 arid 
211 may be connected together via ITSP as well. Each of totalisators 2 and 3 may be 
connected to racecourses 207.208,209,2 10.213.214 or 215. In this way. the processor 
201 is enabled to place bets on races occurring at a very large number of racecourses 
and to receive racing data from totalisators relating to a large number of races. The 
system of the present invention allows users to bet on an extremely wide range of races, 
increasing the attractiveness of the system for users. 

Figure 3 shows the system for providing live or archive video to users. 

Figure 3 is based upon Figure I but is simplified, a number of items being omitted for 
clarity. At the centre is the system 303 according to the invention, 303. The system 
includes a processor 3 1 2 which is connected to a communications network 302, for 
example the internet. Also connected to the communications network is a betting, 
terminal 301, for example a user's PC. Further, a video supplier 304 is also connected 
to the communications network. Two lines^re shown extending from the video 
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supplier 304 to the communications network to show that the video supplier 304 may be 
supplied with a number of different addresses by which it may be accessed from the 
communications network 302. 

The video supplier 304 is further connected to at least two cameras 305.306 located at 
different racetracks and a video archive 307. The video supplier 304 is configured to 
receive signals live from the cameras 305 and 306 as races occur live. The video 
supplier 304 is configured to route video signals from the cameras 305 and 306 to the 
video archive if required or to the communications network or to the system 303. 

The system 303 comprises a pair of monitors 308. Each monitor 308 monitors a stream 
of video data coming from a single camera 305 or 306. The monitor 308 or 309 is 
suitably manually supervised, by an operator watching the video signals. Switch means - 
310 and 3 1 1 are provided attached to each monitor 308 and 309 respectively. When it 
is detected via monitor 308 or 309 respectively that a race has reached a given status, 
for example 'horses going down', switch means 3 1 0 or 3 1 1 may be used to send a 
signal to the processor 3 1 2 indicating that race video may now be watched by users. 
The processor 312 is configured to receive signals from the betting terminal 301 via the 
communications network 302. Information about bets placed by a user of the betting 
terminal 301 is stored by the processor 312 in the user database 313. 

The processor 312 is further connected to the video supplier 304 to send instructions to 
and receive data from the video supplier. When the switch 310 on 311 is used to enable 
users to view race video a signal is sent from the processor to the video supplier 304. 
The video supplier 304 will then supply data identifying where video of the selected 
race may be viewed. This data is stored in the video database 3 1 4. 

Figure 4 shows the structure of the race database 1 06. Races are first of all classified by 
the location at which they occur. They are then classified by a specific race identifier, 
for example the scheduled starting time of the race or a name. For each race, a plurality 
of runners will be identified. Other data may be identified against each race, for 
example the length of the race, the type of the race, the going, the prize money etc. 
Data in the race database may be obtained directly from the racecourse, or more 
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generally from the general data centre 1 10. Wetherby's or Tattershalls. Typically, race 
data in the race database is entered up to date the day before a race occurs. 

Figure 5 schematically shows the structure of a bet database 105. It shows bet data for 
three users, users 1. 2 and 3. For each user, there is a list of bets placed by the user 
identified by the particular race, the type of bet placed, the stake placed and the horses 
selected, if necessary with the positions in which the user has bet the horses will finish 
the race. Further, for each user, there will be additional information, such as the 
account number and password. It may also be recorded whether the user has purchased 
a licence to view archive videos (which will be explained further below). Further, as 
will be further explained below, each user may enter a list of horses which the user 
wishes to follow. These are entered in the "user's horse list" box. 

Figure 6 schematically shows the structure of the account database 104. For each user, 
for example user I, a password, account number and balance may be entered. The 
processor 103 may include an account management means whereby debits and credits 
may be applied to a user's account. 

Suitably, the system operates on an account credit system. The system will not permit 
any bets to be placed unless the account for the given user is in credit. The account 
' database suitably includes a transaction history showing a list of all transactions made 
by the user. The database also includes further information about the user. For 
example, bank account details, including if necessary bank sort code and a bank name 
may be included. The p6stal address, e-mail address, fax number and telephone number 
of the user may be entered. A spend limited to the determined by the operator of the 
system or by the user themselves may be entered. The spend limit will limit the amount 
of money which may be spent on any single day by a given user. 

Figure 7 schematically shows the content of the archive database 1 07. The archive 
database includes three fields One includes archived user account data. Data from the 
transaction history of a user account which is older than a certain age (for example one 
month) may be removed from the transaction history and entered into the user account 
archive. ' 
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Data relating to races which have been finished may be entered into the archive 
database. For example, all data relating to a race in the race database which finished 
more than one day ago or was cancelled more than one day ago may be written into the 
finished races database, along with the results of the race. 

A general archive is also provided for archiving other data, for example a record of 
other information provided by the system. 

Figure 8 schematically shows the content of the research database 108. 

The research database is broadly divided into five fields: 
data relating to horses 
data relating to trainers, 
data relating to jockeys 
data relating to racecourses 
data relating to race results from the past. 

Each of these fields may be extensively linked to other fields. For example, information 
about a given horse in the horse data field may be connected to information about its 
trainer in the trainer data field, and information about jockeys who have ridden the 
horse in the past in the jockey data field, information about races in which the horse has 
raced in the results data field. In this way. a user of the research database may be able 
to collect a very large amount of information about a subject of interest to the user very 
quickly. 

Figure 9 shows the steps involved in registering a new user of the system. 

The system 102 is configured to operate as a server for example a web server. To 
commence use of the system 102, a new user using, for example PC 101. must first of 
all request an electronic application form from the processor (step 1). 
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Before the application form is sent, the processor is configured to send a signal which 
checks the configuration of the new user terminal 101 in step 2. This is to confirm that 
the new user has the required software, processing speed, memory capacity and display 
required to use the system 102. In step 3, if the user terminal cannot be made suitable 
for using the system, the process will end in step 4. 

If the user terminal does not have the required software, the system may be configured 
to direct the user to a source of suitable software, for example a website from which the 
software may be downloaded. 

When the user terminal is configured so that it can operate the system of the invention, 
an application form is transmitted to the user in step 4. In step 5. the new user 
completes the application form and transmits the application form to the processor via 
the internet 100. In step 6. the processor will check the form. 

In a first step 7. the processor checks to ensure that all the information is present. If 
information is found to be missing, the processor sends, in step 8. a request for missing 
information. In step 9. the user will resubmit the electronic application form including 
the missing information. In step 10, the processor assesses whether the application can 
be accepted. The processor will run a number of checks. 

The user must be above a certain age. specified by the law, below which betting is not 
permitted. 

In some parts of the world, betting is not permitted at all. The processor will check that 
the person is not located in a state or country in which betting is not permitted. 

The processor may be configured to inspect external databases, for example police 
records, to confirm whether or not the user has a criminal record or if otherwise 
ineligible for using the system. If for any reason the user does not meet the 
requirements, the process ends in step 11 and a signal is sent to the user refusing their 
application. 



29 

If the application form is accepted, the processor transmits to the user confirmation that 
their application has been accepted in step 12. The processor may assign a password to 
the user or the user may be requested in step 1 3 to enter a password. In step 14. the user 
is requested to enter the password again, as a check. If it is correct, the password is 
entered in the user database along with the new user information in step 15 and use of 
the system may commence. 

Figure 10 shows the steps involved when a registered user starts to use the system. In 
step 16. a logon screen is transmitted by the processor to the betting terminal upon 
request by the user. In step 17. the user completes the logon screen by entering the 
password and name and any other data requested. In step 1 8, the completed logon 
screen is transmitted to the processor for checking. In step 19. the processor checks the 
completed logon screen. In step 20. if information appears to be incorrect or missing, 
the processor will instruct the user to complete the logon screen again. The user may be 
given three attempts to logon correctly. If the user fails to logon correctly after three 
attempts, further attempts to logon from the given betting terminal may be prevented. 
In the alternative, in a manner not shown in Figure 1 0. the user may be given a chance 
to logon using a different logon screen which requires other information which will be 
known only to the user, for example a different password, confidential information such 
as the user's bank account number etc. This different logon screen, when completed, is 
checked by the processor in step 1 9 in the same way as the first logon screen. 

If the logon information received by the first logon screen or by the second logon screen 
is correct, the user is permitted to use the system. The processor will transmit to the 
user information prompting the user to choose what action to take (step 2 1 ). For 
example, the user may be logged on to a webpage which presents the user with a 
number of choices. The user may select betting in step 22 which will be further 
described below. The user may select information services in step 23 which will be 
described further below. The user may seject account management in step 24. If the 
user selects account management, the user may further select to view their account in 
step 25, to pay funds into their accounts in step 26 or to withdraw funds from their 
account in step 27. 
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Figure 11 is a schematic illustration of the steps involved to commence betting. In step 
28, the user selects to start Detting. 

In step 29 the user may choose to view bets which have already been made. The user is 
also given the option of selecting betting by searching horses (step 30) or by searching 
races (30a). 

In a first embodiment the user is given an opportunity to create a database of horses 
which are of interest to the user, in step 31 . the user enters a a part of a horse name as a 
search parameter and transmits it to the processor. For example, the user may enter the 
first three letters of the horses name. In step 32. the processor will, on receipt of the 
search request, search for the horse in the research database. 

If in step 33. horses are located which match the search parameter entered by the user, a 
list of the horses located is sent to the user in step 34 to confirm or select which horse 
was intended. If, however, no horse can be located which matches the criteria, the 
processor sends a signal to the user instructing them to either enter the search parameter 
again or to cancel the search request. 

The user may confirm in step 35 at least one horse from the horse data located by the 
processor. If no horse is located, the process returns to step 34 and the user is again 
prompted to enter a search parameter in step 36 or to cancel the search request. If the 
user confirms at least one horse from the horse data located by the search in step 35, a 
signal is sent to the processor which then records the selected horse in the user's list of 
horses of interest. The user may then proceed to step 37, in which the user instructs the 
processor to search for races in which the horse is running. If the user has already 
entered at least one horse in the user's list of horses of interest, the user may proceed 
directly to step 37 from step 30. 

Figure 12 shows the steps involved in placing a bet on a horse by searching for the 
horse among current race data. 
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In step 38. the user selects to search among race data for a specific horse. In step 39. the 
user may select a horse to be searched and transmits the selection to the processor. In 
step 40. the processor searches the list of forthcoming races in the race database to see if 
the horse is running in any race. In step 42. if the horse is not located, the processor 
then sends an instruction to the user to enter a different horse name or to cancel the 
research request. If. however, the horse is found to be running in at least one race, data 
relating to the races in which the horse is running is sent to the user in step 43. together 
with a betting entry form which will be described further below. In step 45. the user 
completes the betting entry form and transmits it in step 46 to the processor. The 
processor will then check the betting entry form in step 48. The processor will do this 
by checking that the race selected is in the race database and that the horse selected is in 
the race database. The processor will then check that the type of bet has been entered 
correctly and that the appropriate number of horses and. if necessary, positions, have 
been entered for the horses as required by the type of bet. The processor will then check 
to ensure that betting rules have not been infringed. In particular, the processor will 
check to see if the user is permitted to place the type of bet identified in the bet entry 
form. The processor will check to ensure that entering the bet will not exceed the daily 
spend limit specified in the user database. 

If the betting entry cannot be accepted, the processor instructs the user to change the 
betting entry if possible or to cancel the betting request. If the betting request is 
accepted, the processor will transmit a copy of the entry form back to the user to 
confirm in step 50. For example, it may appear as a pop-up window on the user's 
screen. If the user in step 51 does not confirm that the betting entry is correct, the 
processor may instruct the user to change the betting entry or to cancel the bet request 
(step 49). If the bet is accepted, the betting entry is entered into the bet database as an 
entered bet in step 52. In step 52a. the bet data is sent to the totalisator system. 

Figure 13 schematically shows the steps involved in placing a bet by selecting races. In 
step 53, the user selects betting by races. In step 54. the user selects a day on which 
races may occur. In step 55. the processor transmits to the betting terminal of the user a 
list of races for the selected day. if any. The user may then in step 56 select a given race 
from the list of races and transmit the selection to the processor. In step 57. the 
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processor will inspect the race database for race data relating to the selected race and 
will transmit it to the user. The data may be transmitted in the form of or accompanied 
by an electronic betting entry form which will be described further below. In step 58. 
the user completes the betting entry form. In step 59. the user transmits the completed 
betting entry form to the processor using the betting terminal. In step 60. the processor 
checks the betting entry form, in the same way as step 47 of Figure 12. The process 
then continues through steps 61. 62. 63, 64. 65 and 66 which correspond to the steps 48. 
49, 50. 5 1 . 52 and 52a of Figure 1 2. 

Figure 14 schematically shows the steps involved in completing the betting entry form. 
In step 67. the betting entry form is transmitted to the betting terminal of the user. In 
step 68, the user selects a bet type. For example, the betting entry form may be 
displayed as a web pagc : on the betting terminal of the user. The web page may display 
a plurality of buttons, each corresponding to a given bet type. Alternatively, the system 
may scroll through a plurality of different bet types in turn as shown in Figure 14. For 
example, in step 69 the user selects whether to place a win/place bet. If a win/place bet 
is selected, the horse which is predicted to win is selected in step 70. In step 71 , the 
user selects whether to place an exacta bet. If an exacla bet is selected, the user enters 
the first horse and the second horse in step 72 and 73 respectively. In step 74. the user 
decides whether to place a trifecta bet. If a trifecta bet is selected, the respective horses 
are selected in steps 75, 76 and 77. In step 78. the user decides whether to place a 
jackpot/placepot bet. If this type of bet is selected, the user selects the respective horses 
in steps 79-84 as shown. After the respective steps 70. 73, 77 or 84. depending upon the 
type of bet selected, the user enters the slake in step 85 and then transmits the bet to the 
processor in step 86. 



Figure 1 5 is a schematic illustration of the process for transmitting live video of 
a race. In step 99, the video supplier starts to transmit video signals to the processor. 
The processor is configured to monitor the signals in step 100. The signals may be 
monitored for example by an operator of the system watching the video signals. At 
some point, the race will approach a stage at which betters will wish to view it. The 
operator then decides, subjectively, when to make video available for users to watch in 
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step 101 . When this decision is made, the operator uses the switch device 310 or 31 1 
shown in figure 3 to select the video screen of the appropriate race for screening. For 
this purpose, the switch may be provided by software such as PC Anywhere (trade 
mark). This switch enables the operator to send instructions to start transmission of 
video, to start recording of video, to stop transmission of video or to stop recording of 
video.. 

In step 102, on instructions of the operator, the video supplier is instructed by the 
processor to make the video screen available and to assign to the supply of live screen 
video signals a location address in a communication network 302. 

The video supplier may also be instructed to record the video simultaneously, as will be 
explained further below 

In step 104. the video supplier transmits the communications network locations address 
to the processor. In step 1 05, the processor enters the location address in a video 
database. 

At some point, a user who has bet upon the race may wish to view a video of the race. 
In step 1 06. the user uses the betting terminal to transmit a video request to the 
processor. Before the processor permits the user to view the video, the processor will 
first check in the bet database to confirm that the user has placed a bet on the race 
identified by the video request. If no bet has been placed by the person making the 
request for a video on the race, video cannot be provided and the process ends in step 
107. A signal is sent to the person making the request to indicate that the video will not 
be made available. 

If, however, a bet has been placed by the person making the request and the betting data 
has been entered by the processor in the bet data store (step 107) the processor will 
permit the person making the request to view video of the race. In order to allow this to 
happen, the processor transmits code to the betting terminal. This code will comprise 
instructions for the betting terminal to perform a number of acts: 
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1 . the code will activate means in the betting terminal automatically to allow the 
video to be viewed. For example, where the betting terminals comprises a personal 
computer, the code may open a window for viewing video, for example, a Realplayer or 
Mediaplayer (trade mark) window. 

2. the code will include the location address on the communications network for 
the stream of live video signals from the video supply 304. 

The code is preferably configured so that the betting terminal is enabled to view the 
video. The betting terminal is used to send a request to the location address for video 
stream automatically so that the video stream can be watched on the user terminal. 
Preferably, the video the supplier 304 is configured to apply a different location address 
to video for each race transmitted. In this way, when a betting terminal is provided with 
a location address for viewing video, the betting terminal can only be used to view one 
race and not any other races which may occur afterwards. 

Termination of the video stream may occur by: 

1. 'he user terminating the viewing process at the betting terminal 

2. the stream of video from the video supplier 304 terminating, or 

3 the supply of video being switched off by the switch 3 1 0 or 3 II by the operator. 

Video is normally terminated after all or some of the horses have completed the race 
(step 112). 

Figure 17 is schematic illustration of the steps involved in viewing archived video. 

As noted above in figure 1 6. the video supplier may be configured to record the live 
video data. 

This archived video may be made available to users of the system of the invention as 
shown in figure 1 7. In step 1 1 3. a request to view archived video is received by the 
processor from a betting terminal. 
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However, as video footage of races is copyright material, it may not be made available 
to users unless those users have paid a licence fee. The processor is configured in step 

1 14 to investigate if the user has paid a licence fee to view video archive. 

The licence used in the present system is typically a blanket licence permitting the user 
to view any archived video within the period of the licence. 

If the user does not have a licence, the processor will send to the betting terminal an 
electronic licence application form in step 1 15. The electronic licence application form 
will typically comprise a statement of undertaking by the user that they will not make 
the copyright material available to anybody else without the permission of the system 
operator and that it will only be used for home viewing and not for profit. Other 
undertakings may be provided as is required by contract with the supplier of the video 
material. In step 1 16, the user completes the licence application and transmits it in step 
1 1 7 to the processor. In step 1 1 8. a licence fee is transmitted by the user to the 
processor. For example, this may be accomplished using the betting terminal by 
transmitting to the system account details and by transmitting to the financial institution 

115 of the user an order to pay to the system the required sum for the licence purchased. 

The licence purchased will have a time limit of may be one month, two months or a 
year. The fee paid will depend upon the duration of the licence. 

The processor will check the licence application form and will confirm that the licence 
has been received in step 119. If this has been received, the licence details are entered 
in the video database. 

r 

After step 1 19 or, after step 1 1 4 if the user already has a licence, the processor is 
configured to send to the video supplier a request for video. The video supplier is 
configured to search the video storage 307 in step 121 . If no video of the race requested 
by the user is present, a signal indicating that the video cannot be located is sent by the 
video supplier to the processor in step 123. In turn, the processor sends to the user a 
notification that the video cannot be located and requesting the user to re-enter the video 
data or cancel the request. If the video can be located, the archived video is allocated a 
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location address on the communications network 302 by the video supplier to make the 
archive video available for downloading. The location address is then transmitted to the 
processor. 

The licence granted to the user to view archived material may be located in the 
processor. In the alternative, a licence system which is resident in the user's betting 
terminal may be used, for example using the software BRM (trade mark) designed for 
this purpose. 

Using this software, a key is transmitted to the betting terminal. A key has a time limit. 
So long as the time limit has not expired, the key permits video file downloaded on the 
betting terminal to be viewed. If. however, the key has expired, the key will not permit 
the downloaded videos to be viewed. However, the key only needs to be sent once per 
term of licence purchased. In step 126. the process checks whether or not a key has 
already been sent to the betting terminals. If it has not. a data package comprising the 
location address and the key is transmitted to the betting terminal in step 1 27. If a key 
has already been transmitted, the processor only sends the location address of the 
archived video to be downloaded to the betting terminal in step 1 28. 

In step 129, which follows on from step 127 or 128 as appropriate, the belting terminal, 
in response to receiving the location address from the processor automatically sends the 
request for archive video through the communication network 302 to the location 
address. As a result, a file comprising the archived video is downloaded over the 
communication network 302 to the betting terminal in step 130. The user of the betting 
terminal may then view the video file at any time during the period of the licence 
covered by the key. 

The present invention has been described above purely by way of example and 
modification can be made within the spirit of the invention, which extends to 
equivalents of the features described and to method features of apparatus claims. The 
invention also consists in any individual features described or implicit herein or shown 
or implicit in the drawings or any combination of any such features or any 
generalisation of any such features or combinations. 
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CLAIMS: 

1 . An interactive race betting system comprising: 

race data input means for receiving race data, the race data including an 
identification of at least one race and data relating to runners in the at least one race. 

race data storage means. 

means for transmitting race data to a betting terminal. 

bet input means for receiving bet data from a betting terminal, the bet data 
including a selection of at least one race, a selection of at least one runner and an 
identification of the betting terminal. 

bet data store means for storing the input bet data as a data entry . 

means for receiving a request for video of at least one race from a requesting 
betting terminal. 

a processor configured to inspect the bet data in the respective storage means 
when a request for video is received, and to give a signal if the at least one race is 
identified by at least one data entry in the bet data storage means which also identifies 
the requesting betting terminal and 

means for allowing in response to the signal the requesting betting terminal to 
display video of the at least one race. 

2. A race betting system according to claim 1 , wherein the identification of the at 
least one race comprises an identification of a. racecourse and an identification of a race 
time. i 

3. A race betting system according to claim 1 or 2, wherein the race status data 
includes an estimate of the time which will elapse before the race start. 

4. A race betting system according to claim 3, wherein the processor is configured 
to inspect the bet data store when the time to the start of at least one race is less than or 
equal to a defined time. 
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5. A race betting system according to any preceding claim, further comprising 
account management means, comprising account data storage means for storing account 
data comprising- for each of a set of defined users, at least an account balance. 

6. A race betting system according to claim 5. wherein the account management 
means is configured to reduce the account balance of a user in response to betting data 
received from a betting terminal operated by the user. 

7. A race betting system according to claim 5 or 6, wherein the bet data further 
comprises an identification of a stake for a bet. the account management means being 
configured to reduce the account balance for the user by the stake in response to betting 
data received from a betting terminal operated by the user. 

8. A race betting system according to claim 5, 6 or 7, wherein the bet data further 
includes an identification of the type of bet, the account management means being 
configured to reduce the account for the user by an amount corresponding to the type of 
bet in response to betting data received from a betting terminal operated by the user. 

9. A race betting system according to any of claims 5 to 8. wherein the processor is 
configured to transmit to at least one totalisator device bet data corresponding to the 
race selection and runner selection of a data entry and reference data, the processor 
being further configured to record the reference data in the data entry in the bet data 
store. 

1 0. A race betting system according to claim 9, wherein the processor is further 
configured to receive from a totalistator device race result data, including an 
identification of a race, and an identification of at least one sum won, the identification 
of the sum won being accompanied by reference data, the processor being configured to 
search the bet data store to identify the bet data entry with the same reference data and 
to operate the account management means to credit the account of the user of the betting 
terminal identified by the betting data entry with a sum corresponding to the sum won. 
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11. A race betting system according to any preceding claim, wherein the bet data 
includes an identification of the type of bet. 

12. A race betting system according to claim 1 1 . wherein the type of bet is win or 
place bet. 

13. A race betting system according to claim 1 1 . wherein the bet type is an exacta 
bet. the bet data further comprising identification of a second runner. 

14. A race betting system according to claim 1 1 . wherein the bet type is a tri fecta bet 
and the bet data further comprises an identification of a second and third runner. 

1 5. A race betting system according to claim 1 1 , wherein the bet type is a jackpot / 
placepot bet and the bet data comprises an identification of a plurality of runners in a 
specified order. 

1 6. A race betting system according to any of claims 1 1 to 1 5. wherein the processor 
is configured to record the type of bet in the bet store. 

17. race betting system according to any preceding claim, wherein the processor is 
configured to record the stake in the bet data store. 

1 8. A race betting system according to any preceding claim, wherein the processor 
is configured to inspect input bet data to check for a password, the processor being 
configured to reject the bet data i f the password is absent or incorrect. 

19. A race betting system according to any preceding claim, wherein code is 
transmitted to the betting terminal is configured to allow the terminal to receive video of 
the race from the processor, the processor being configured to transmit video of the race 
to the betting terminal. 
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20. A race betting system according to any preceding claim, further comprising an 
archive data store comprising archive data relating to at least one of the runner, race,, 
racecourse, race results, trainer or rider 

input means for receiving-a search request from a betting terminal, the processor 
being configured to search for data in the archive in response to the search request to 
produce search result data, and 

means for transmitting search result data to the betting terminal 

21 . A race betting system according to any preceding claim, further comprising 
means for receiving from a betting terminal option data relating to at least one of a 
runner, race, racecourse, trainer or rider. 

an option data store for storing the option data received as a data entry, the 
process or being configured to inspect the race data store at regular intervals and the 
option data store and to produce option match data if the data in any data entry matches 
race data irt the race data store, and ^ 

means for transmitting to the betting terminal identified by the option data entry 
the option match data, comprising data relating to the race. 



22. A race betting system according to any preceding claim, further comprising 
means for transmitting a request for video location data to a video data source, 
means for receiving from the video data source video location data and a video 
location data store for storing the video location data. 

23. A race betting system according to claim 23, wherein, when a request to view a 
selected race is received from a betting terminal, the processor is configured to 
search in the video location data store for video location data relating to the 
selected race and, in order to allow the betting terminal to display video of the 
selected race, the processor is configured to transmit to the betting terminal the 
video location data. 

24. A race betting system according to any preceding claim, further comprising 
means for receiving from a requesting betting terminal a request for archived 
video of a race which has finished, a betting terminal licence data store in which 
betting terminals which have licences to receive archived videos are entered, the 
processor being configured to search the betting terminal licence data store and, 
if the requesting betting terminal has a licence, to permit the requesting betting 
terminal to access archived video. 



25. A race betting system according to claim 24. wherein the processor is configured 
to transmit to the requesting betting terminal code which allows the betting 
terminal to display archived race video for a specified period of time. 

26. A race betting system according to any preceding claim, further comprising 
means for transmitting a request for archived video location data to an archive 
video data source, means for receiving from the archive video data source video 
location data and a video location data store for storing the archive video 
location data. 

27. A race betting system according to claim 26. wherein, when a request to view an 
archived race is received from a betting terminal, the processor is configured to 
search in the archived video location data store for archived video location data 
relating to the archived race and. in order to allow the betting terminal to display 
video of the archived race, the processor is configured to transmit to the betting 
terminal the archived video location data. 

28. A betting terminal for use with the betting system of any preceding claim, 
comprising input means for receiving race data from the system, bet data input 
means for inputting bat data, bet data transmitting means for transmitting the bet 
data to the system, means for transmitting to the system a request to view a race 
and means for viewing the race when allowed by the system. 

29. A betting terminal according to claim 28. further comprising means for 
transmitting to the system payment instructions. 

30. A betting terminal according to claim 28 or 29. wherein the means for viewing 
the race comprises means for receiving from the system video location data and 
means for transmitting a request to the location identified by the video location 
data a request to view video data and means for receiving from the location the 
video data. 



31. An interactive race betting system comprising: 

race data input means for receiving race data, the race data including an 
identification of at least one race and data relating to runners in the at least one race, the 
racecourse, trainer or rider, 
race data storage means, 

means for receiving from a betting terminal option data relating to at Jeast one of a 
runner, race, racecourse, trainer or rider. 



an option data store for storing the option data received as a data entry. 
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a processor configured to inspect the race data store at regular intervals and the option 
data store and, if data in the race data store matches data in an entry in the option data 
store, to transmit to the betting terminal identified by the option data entry, the race 
data of the data entry, and 

bet input means for receiving bet data from the betting terminal. 

32. An interactive race betting system comprising: 

race data input means for receiving race data, the race data including an 
identification of at least one race and data relating to runners in the at least one race. 

race data storage means. 

means for transmitting race data to a betting terminal. 

bet input means for, receiving bet data from abetting terminal, the bet data 
including a selection of at least one race and a selection of at least one runner 

bet data store means for storing the input bet data as a data enlry. 

means for transmitting a request for race video location data to a video data 
source, means for receiving from the video data source the race video location data and 
a video location data store for storing the race video location data 

means for receiving a request for video of at least one race from a requesting 
betting terminal, 

a processor configured to search in the race video location data store for video 
location data relating to the selected race and. in order to allow the betting terminal to 
display video of the selected race, to transmit to the betting terminal the video location 
data. 

33. A method of interactive race betting, comprising receiving race data, the 
race data including an identification of at least one race, the status of the race and data 
relating to runners in the race. 

transmitting race data to a remote betting terminal, receiving betting data from a 
betting terminal, the bet data including a selection of at least one race and at least one 
runner in the race and an identification of the betting terminal, storing the bet data in a 
bet data store as a data entry, receiving a request for video from a requesting betting 
terminal, inspecting the bet data store when a request is received, giving a signal if the 
at least one race is identified by at least one data entry in the bet data store means, 
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which also identifies the requesting betting terminal and allowing in response to the 
signal the requesting betting terminal to display a video of the at least one race. 

34. Programme code for controlling one or more processors to implement the 
method of Claim 33. 

35. a carrier medium carrying the computer programme code according to the 
invention. 
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